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METHODS AND APPARATUS FOR PROCESSING 
ORDER RELATED MESSAGES 

BACKGROUND OF THE INVENTION 

5 In general, customers using an online order processing system may order products 

using a local computer (e.g., a client) over a connection to a vendor, such as by dialing in 
over a modem to a computer network, such as the Internet, to the vendor's computer (e.g., 
server). Typically, the customer can enter in ordering information into a user interface 
provided by the vendor's order processing software over the connection which is 

10 displayed on a visual display of the customer's computer. For example, the customer can 
begin by entering in the customer's name and address if the customer is interested in a 
particular product, and the customer can enter in the name and/or model number of the 
product that the customer is considering ordering. The customer can then receive product 
information including pricing information, configuration information, and so on. 
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After receiving this product information over the network connection, the 
customer can decide whether to place the order or to hold off submitting the order until a 
later time. If placing the order, the customer can indicate that the customer wishes to 
submit the order by further manipulating the computer display provided by the vendor's 
5 computer. The vendor's order processing software may require the customer to submit 
additional information, such as a purchase order number and shipping address. After 
entering this information, the order processing software processes this information and 
accepts (or rejects) the order. If the order is accepted, the vendor's computer indicates the 
acceptance and typically provides the customer with verification information, such as a 
1 0 confirmation number or order number, that the customer writes down on a piece of paper 
or prints out on a printer connected to the customers' local client computer. 
T1 If the customer is not sure of the product to be ordered, the customer can request 

information from the vendor's order processing software, which is then displayed on the 
^1 customer's client computer as one or more screens of information provided over the 

a 1 5 network connection by the order processing software. The customer can then read 
H through the displayed screens, or print them out to read the hard copies of the information 

h* for comparison with the customer's requirements and needs. If the customer is a business 

f I (e.g., wholesaler, distributor, value added reseller or VAR, original equipment 

?5 ' manufacturer or OEM, or other business), then the customer can check or compare its 

20 own inventory, requests from its customers (e.g., its retail customers) and other 

information against the information provided by the vendor's computer to determine what 
products and configurations of those products to order from the vendor. In addition, the 
customer can use the ordering information (from a display screen or printout) and then 
enter (e.g., type in at a keyboard or copy and paste using a mouse) this information into an 
25 ordering application or other application (e.g., customer's inventory application) that the 
customer maintains at its own local computer. 

In another conventional approach, a customer can log onto a vendor's web site 
over the Internet, and view information about products for sale at the web site provided 
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by the vendor's order processing software from the vendor's web server. The customer 
can select products from displays on the web site for an order and can then submit the 
order through the web site. The web site then displays a confirmation number to the 
customer, who can print it out if desired. 

5 

SUMMARY OF THE INVENTION 

The conventional approaches to the operation of order processing software over a 
network as described above have a number of deficiencies. After submitting the order, 
the customer can obtain information, such as a confirmation number, about the order, but 

10 then must typically re-enter the confirmation number and order information into the 
customer's own ordering application and local order database on the customer's 
computer. That is, the customer must enter the order information twice, once when 
entering the order information into the vendor's order application (e.g., provide order 
information in the vendor's web page), and a second time when entering the information 

1 5 into the customer's own order application and local order database (referred to as a 

double entry problem). The customer may be able to copy text from the vendor's order 
application (e.g., copy a confirmation number from a web page) and then paste the text 
into an input display for the customer's application, but this approach involves a manual 
operation of copying and pasting for each piece of information to be input into the 

20 customer's application. 

In general, the customer cannot directly read in the data provided by the vendor's 
order processing software into the customer's ordering application. In particular, this is a 
problem if the customer is a large VAR or OEM, who orders products and parts from the 
vendor to incorporate into the customer's own systems, for sale to end-users of the 

25 systems. For example, large, complex systems, such as complex commercial computing 
systems may be composed of many components that an OEM receives from several 
vendors. Such components can include central processing units, data storage devices, 
output devices, routers, switches, and other computing or electronic devices. The OEM 
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customer cannot readily obtain pricing and ordering information about the vendor's 
products to incorporate into the customer's own applications and databases without 
manually reentering or transferring the information. For example, if the delivery dates of 
the vendor's products change (e.g., are delayed), then the OEM must reenter or manually 

5 change the delivery dates to incorporate those changes into its own ordering and 

manufacturing assembly software so as to provide accurate delivery dates to its own end- 
user customers for systems provided by the OEM that incorporate the vendor's products. 

In contrast, the invention is directed to techniques for processing order messages 
in predefined formats that substantially overcome such limitations of conventional 

10 systems. The predefined formats, such as document formats based on an extended 
markup language or XML, can be readily used by a customer that is exchanging order 
messages with a vendor's order server. These predefined formats enable different clients 
to provide order messages in a format that can be readily received and processed by an 
order message processing application (e.g., order message manager) configured according 

1 5 to embodiments of the invention at the order server. The vendor' s order processing 
application can sort the messages into predefined types so that different message 
processing modules can efficiently process the messages, because each module is 
designed to process a specific type of message indicated by the predefined order message 
formats. Because the messages are based on predefined formats, the sorting process can 

20 proceed automatically without the intervention of a human operator. 

The vendor's ordering processing application can then return messages in 
predefined formats to the customer in response to the input order messages. Because 
embodiments of the invention produce output order messages in the predefined format, 
the customer's ordering application can then readily incorporate returned messages (i.e., 

25 output order messages from the vendor) into the customer's own ordering application and 
order databases. If receiving returned messages from different order processing 
applications from the vendor or different applications from several different vendors that 
follow the same predefined formats, then the customer's own ordering application can 
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readily incorporate the returned order messages received from different sources and 
integrate the returned data in the messages into a unified customer database, without 
requiring that the customer reenter the data received from the vendor or otherwise engage 
in a cumbersome manual transfer of the data from one format to another for entry into the 
customer's database(s). 

In one embodiment, the invention is directed to a method, in an order server, for 
processing order messages. The method includes a step of receiving a first message of 
the order messages over a network, where the first message comprises a first document 
organized in a first predefined format. The method also includes steps of obtaining a first 
data set from the first message based on the first predefined format of the first document 
in response to receiving the first message, obtaining a second data set by processing the 
first data set of the first message in response to obtaining the first data set, and providing 
over the network the second data set in a second message comprising a second document 
organized in a second predefined format suitable for use by an ordering application. Thus 
the customer's ordering application receives a response to the customer's order request 
(e.g., check order status request) in a format that the ordering application can readily 
process and incorporate into the customer's order database without requiring any manual 
operation by the customer. 

In another embodiment, the order server is a vendor order server and the ordering 
application is a customer ordering application. The method additionally includes the 
steps of receiving a first extended markup language document from the customer ordering 
application, obtaining the first data set from a first predefined element of the first 
extended markup language document, invoking an ordering function based on a message 
type defined in a second predefined element of the first extended markup language 
document to generate the second data set, and providing the second data set in a third 
predefined element in a second extended markup language document to the customer 
ordering application. As a result, the order messages can include XML (extended markup 
language) documents, which provides a readily processed language for the predefined 
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XML elements provided in the documents. 

In an additional embodiment, the method includes directing the first message to a 
first message processing module of a plurality of message processing modules. Thus the 
order server directs the order message to a particular module for processing. 

5 In a further embodiment, the method includes parsing the first message to 

determine a message type that identifies an ordering function for the first message, and 
directing the first message to the first processing module based on the message type. As a 
result, the order message is processed by a particular module that is designed to process 
that type of order message, enabling more efficient processing than if all messages were 

1 0 processed by the same module. 

The method includes, in another embodiment, interacting with an order database 
based on the first data set and based on a message type of the first message to generate the 
second data set. For example, the order server can receive a status inquiry regarding the 
status of a previously submitted order in an input order message from a customer. Then, 

1 5 the order server can obtain the current status from the order database to return to the 
customer in an output order message from the order server to the customer. 

In another embodiment, the method includes performing an ordering function 
based on the first data set and based on a message type of the first message to generate the 
second data set. For example, the message processing module performs a specific 

20 ordering function, such as order status inquiry, new order submittal, order configuration, 
and so on. 

In a further embodiment, the second predefined format is suitable for integration 
into a database maintained by the ordering application. Thus the output order message 
received by the customer from the order server can be in a format that the customer's 
25 ordering application can read and readily transfer to the customer' s own database of order 
information. 

In an additional embodiment, the first document and the second document are 
extended markup language documents. Thus, the documents provided in the order 
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messages can be based on XML (extended markup language), which provides a readily 
processed language for the predefined XML elements in the documents. 

In some embodiments, the techniques of the invention are implemented primarily 
by computer software. Such computer program logic embodiments, which are essentially 

5 software, when executed on one or more hardware processors in one or more hardware 
computing systems cause the processors to perform the techniques outlined above. In 
other words, these embodiments of the invention are generally manufactured as a 
computer program stored on a disk, memory, card, or other such media that can be loaded 
directly into a computer, or downloaded over a network into a computer, to make the 

1 0 device perform according to the operations of the invention. In one embodiment, the 

techniques of the invention are implemented in hardware circuitry, such as an integrated 
circuit (IC) or application specific integrated circuit (ASIC). 

BRIEF DESCRIPTION OF THE DRAWINGS 

1 5 The foregoing and other obj ects, features and advantages of the invention will be 

apparent from the following more particular description of preferred embodiments of the 
invention, as illustrated in the accompanying drawings in which like reference characters 
refer to the same parts throughout the different views. The drawings are not necessarily 
to scale, emphasis instead being placed upon illustrating the principles of the invention. 

20 Fig. 1 is a block diagram illustrating a sample computing system environment 

including a client computer, an order server, and an order database configured according 
to embodiments of the invention. 

Fig. 2 is a flow chart of a procedure for processing an input order message and 
providing a result performed by an order server configured in accordance with 

25 embodiments of the invention. 

Fig. 3 is a block diagram of an order message sorter in an order message manager 
of an order server configured in accordance with embodiments of the invention. 

Fig. 4 is a block diagram of a message processing module in an order message 
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manager of an order server configured in accordance with embodiments of the invention. 

Fig. 5 is a flow chart of a procedure for processing an input document of an input 
order message performed by an order server in accordance with embodiments of the 
invention. 

5 Figs. 6A and 6B illustrate an example of an input document in a predefined 

format configured in accordance with embodiments of the invention. 

Figs. 7 A through 7E illustrate an example of an output document in a predefined 
format configured in accordance with embodiments of the invention. 

1 0 DETAILED DESCRIPTION 

The invention is directed to techniques for processing order messages in 
predefined formats. The predefined formats, such as document formats based on an 
extended markup language or XML, can be readily used by a customer that is exchanging 
order messages with a vendor's order server. These predefined formats enable different 

1 5 clients to provide order messages in a format that can be readily received and processed at 
the order server by an order message processing application (e.g., order message 
manager) configured according to embodiments of the invention. The vendor's order 
processing application can sort the messages into predefined types so that different 
message processing modules can efficiently process the messages, because each module 

20 is designed to process a specific type of message indicated by the predefined order 
message formats. Because the messages are based on predefined formats, the sorting 
process can proceed automatically without the intervention of a human operator. 

The vendor's ordering processing application can then return messages in 
predefined formats to the customer in response to the input order messages. Because 

25 embodiments of the invention produce output order messages in the predefined format, 
the customer's ordering application can then readily incorporate returned messages (i.e., 
output order messages from the vendor) into the customer's own ordering application and 
order databases. If receiving returned messages from different order processing 
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applications from the vendor or different applications from several different vendors that 
follow the same predefined formats, then the customer's own ordering application can 
readily incorporate the returned order messages received from different sources and 
integrate the returned data in the messages into a unified customer database, without 

5 requiring that the customer reenter the data received from the vendor or otherwise engage 
in a cumbersome manual transfer of the data from one format to another for entry into the 
customer's database(s). 

Fig. 1 is a block diagram illustrating a computing system environment 20 
including a client 22, client database 31, network connection 24, an order server 26, and 

10 an order database 28 configured according to embodiments of the invention. 

The client (e.g., customer) 22 is any suitable computing system that can be used to 
exchange order messages 50, 52 with an order server 26. In alternate embodiments, the 
client can be a desktop computer, a laptop computer, palmtop computers, or other type of 
computer or electronic device capable of transmitting and receiving order messages 50, 

15 52. The input order message 50 is an order message transmitted from the client 22 

through the network connection 24 to the order server 26. The output order message 52 is 
an order message received by the client 22 through the network connection 24 from the 
order server 26. The order messages 50, 52 are messages preferably based on a tagged 
document format, in which the text of the message is marked with tags indicating format, 

20 category, or other information about the text. In one embodiment, the order messages 50, 
52 are based on an extended markup language (XML) format. A memory of the client is 
encoded with logic instructions for a client ordering process 30, which is a process that 
performs ordering functions on a processor (e.g., microprocessor) of the client 22, such as 
generating input order messages 50, storing the customer's order information in a client 

25 database 3 1 , and receiving output order messages 52 returned from the order server 26. 
The client 22 is in communication with a client database 31 which is any type of suitable 
data storage device (e.g., disk) capable of storing ordering data and other data for use by 
the client 22. 
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The network connection 24 is a communication connection, modem connection, 
or network providing communications between the client 22 and the order server 26. In 
one embodiment, the network connection 24 is a packet-based network, such as the 
Internet based on the TCP/IP (Transmission Control Protocol/Internet Protocol). In this 

5 embodiment, the order messages 50, 52 are based on HTTP (Hypertext Transfer Protocol) 
requests and responses that include the ordering information as tagged documents within 
the request. In such an embodiment, the customer communicates with the order server 26 
through a network browser, such as Internet Explorer (manufactured by Microsoft 
Corporation of Redmond, Washington, USA) or Netscape Navigator (manufactured by 

1 0 Netscape Corporation of Mountain View, California, USA). 

The order server 26 is a server computer, including a processor 32, a memory 34, 
and an input/output interface 36, which are connected by the internal circuitry (e.g., bus 
or other interconnection mechanism) of the order server 26. The processor 32 is any type 
of processing unit (e.g., microprocessor) which preferably operates electronically to 

1 5 process logic instructions. The memory 34 is any type of memory suitable for use with 
the processor 32, and preferably includes volatile memory (e.g., RAM or random access 
memory) and nonvolatile memory (e.g., EPROM or erasable programmable read only 
memory, or disk). The memory 34 stores data such as an input message data set 44, 
which is included as part of the input order message 50, and an output message data set 

20 46, which is the basis for the output order message 52, as will be discussed in more detail 
later. The memory 34 is encoded with logic instructions (e.g., software code, such as 
object code) for an order message manager application 42 which perform on the 
processor 32 to form an order message manager 37. The instructions for the order 
message manager application 42 perform on the processor 32 such that the order message 

25 manager 37 includes an order message sorter 38, that sorts incoming order messages 50 to 
be processed by message processing modules 40 (e.g., 40A, 40B, and 40C). The 
input/output interface 36 provides communications services and connections for the order 
server 26 to the network connection 24 and to the order database 28. The order database 
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28 is any type of suitable data storage device (e.g., disk) capable of storing ordering data 
and other data for use by the order server 26. 

In one embodiment, a computer program product 180 including a computer 
readable medium (e.g., one or more CDROM's, diskettes, tapes, etc.) provides software 
5 instructions (e.g., logic instruction of the order message manager application 40) for the 
order message manager 37. The computer program product 180 can be installed by any 
suitable software installation procedure, as is well known in the art. In another 
embodiment, the software instructions can also be downloaded over a wireless 
connection. A computer program propagated signal product 182 embodied on a 
1 0 propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser 
wave, sound wave, or an electrical wave propagated over the Internet or other network) 
provides software instructions for the order message manager 37. In alternate 
embodiments, the propagated signal is an analog carrier wave or a digital signal carried 
on the propagated medium. For example, the propagated signal can be a digitized signal 
1 5 propagated over the Internet or other network. In one embodiment, the propagated signal 
is a signal that is transmitted over the propagation medium over a period of time, such as 
the instructions for a software application sent in packets over a network over a period of 
seconds, minutes, or longer. In another embodiment, the computer readable medium of 
the computer program product 180 is a propagation medium that the computer can 
20 receive and read, such as by receiving the propagation medium and identifying a 
propagated signal embodied in the propagation medium, as described above for the 
computer program propagated signal product 182. 

In a general summary of the techniques of embodiments of the invention, a 
customer uses the client computer 22 to provide an input order message 50 through the 
25 network connection 24 to the order server 26. The order message manager 37 receives 
the input order message 50 through the input/output interface 36. The order message 
sorter 38 of the order message manager 37 determines what type of message the input 
order message 50 is. The order message sorter 38 then passes the input order message 50 
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to a message processing module 40 that is capable of handling that type of message. The 
message processing module 40 processes the input order message 50, obtains data from 
the order database 28 if need be, and produces an output order message 52 for 
transmission back to the client 22. Figs. 2 through 5 illustrate this order processing 
process in more detail, and Figs. 6A through 7E illustrate sample order documents 300, 
330 that can be incorporated into examples of order messages 50, 52. 

Fig. 2 is a flow chart of a procedure 100 for processing an input order message 50 
and providing a result performed by an order server 26 configured in accordance with 
embodiments of the invention. 

In step 102, the order message manager 37 of the order server 26 receives though 
the input/output interface 36 an input order message 50 sent from the client 22 over the 
network connection 24 to the order server 26. The input order message 50 includes a 
document organized in a predefined format (e.g., XML document), as described in the 
examples shown in Fig. 6A and 6B. The order message manager 37 passes the input 
order message 50 to the order message sorter 38, which evaluates the input order message 
50 (e.g., examines a header or first lines of the message) to determine a type or category 
for the input order message 50. The order message sorter 38 then determines which 
message processing module 40 is suited to process that type of message and passes the 
input order message 50 to that message processing module 40. For example, the input 
order message 50 includes an order status inquiry that requests the status of an order that 
the customer previously sent to the order server 26 through a previous input order 
message 50 that submitted the order. In one particular example, the input order message 
50 is an HTTP request sent from the client 22 over the Internet (i.e., network connection 
24) to the order server 26 that includes the order status inquiry as part of the HTTP 
request. 

In step 104, the message processing module 40 obtains an input message data set 
44 from the input order message 50 by using the predefined format of the document in the 
input order message 50. For example, a status message processing module 40 can 
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examine the document in the input order message 50 (e.g., status inquiry) to determine 
which lines, tagged elements, or parts of the document indicate the order number for 
which the customer wishes to obtain the status, and the customer ID or identifier that 
identifies the customer who submitted the input order message 50. 
5 In step 1 06, the message processing module 40 obtains a resulting or output 

message data set 46 by processing the input data set 44 obtained from the input order 
message 50. For example, the message processing module 40 uses the customer ID and 
order number to obtain information about the status of the order and location of the order 
(e.g., manufacturing, shipping, etc.) from the order database 28. The message processing 

10 module 40 then stores this status information as the output message data set 46 in the 
memory 34 of the order server 26 until ready to send an output order message 52 that 
includes the output message data set 46 to the client 22. Alternatively, the message 
processing module 40 can store the output message data set 46 on the order database 28 
until ready to send the output order message 52 to the client 22. 

15 In step 108, the order message manger 37 provides over the network connection 

24 to the client 22 the resulting output message data set 46 in a response or output order 
message 52, including a document organized in a predefined format suitable for use by 
the client ordering process 30, as described in more detail for the examples shown in Fig. 
7A through 7E. For example, the message processing module 40 of the order message 

20 manager 37 provides status information contained in the output message data set 46 in an 
XML document in an output order message 52, to be sent through the input/output 
interface 36 through the network connection 24 to the client 22. Thus the output order 
message 52 includes an XML document that provides the status information in predefined 
XML format (as defined previously in an XML document type definition document) so 

25 that the client's ordering process 30 can readily interpret the status information, extract 
the status information from the predefined XML document, and then (i.e., without manual 
reentry of the status information) automatically update the status of the order in the client 
database 3 1 . 
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In one embodiment, the client 22 and the order message manager 37 exchange 
messages 50, 52 in a secure manner. For example, the client 22 and the order message 
manager 37 exchange messages 50,52 using a digital certificate approach to verify users 
and/or messages. In addition, the client 22 and the order message manager 37 can use a 
5 secure sockets layer (SSL) approach to provide security for the messages 50,52. 

Fig. 3 is a block diagram of an order message sorter 38 of an order message 
manager 37 performing on an order server 26 in an input order processing environment 
60 configured in accordance with embodiments of the invention. Fig. 3 also illustrates an 
input order message 50-1, which is one example of the input order message 50 of Fig. 1 . 

10 The input order message 50-1 includes an input document 62, which is in a predefined 
format that includes, in one embodiment as shown in Fig. 3, an embedded order type 64-1 
and embedded input data set 44-1. Fig. 3 also shows an extracted order type 64-2, which 
indicates the order type information 64 that the order message sorter 38 has extracted 
from the input document 62. That is, the extracted order type 64-2 includes the same 

15 order type information 64 as the embedded order type information 64-1 of the input 

document 62. In one embodiment, the extracted order type 64-2 is in a different format 
from the embedded order type information 64-1 . See the discussion of the flowchart of 
Fig. 5 for more information on the process of extracting the order type information 64-2 
from input documents 62, sorting input documents 62, and directing input documents 62 

20 to message processing modules 40. 

Fig. 4 is a block diagram of a message processing module 40 of an order message 
manager 37 performing on an order server 26 in an output order processing environment 
70 configured in accordance with embodiments of the invention. Fig. 4 illustrates an 
extracted input data set 44-2 that the message processing module 40 extracts from an 

25 input document 62 containing an embedded input data set 44-1 . Fig. 4 also illustrates an 
output data set 46-1 that the message processing module 40 includes as an embedded 
output data set 46-2 in an output document 68, which is then included in an output order 
message 52. See the discussion of the flowchart of Fig. 5 for more information on the 
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process of extracting the input data set 44-1 from the input document 62, embedding the 
output data set 46-1 in the output document 68, and producing the output order message 
52. 

Fig. 5 is a flow chart of a procedure 200 for processing an input document 62 of 
5 an input order message 50 performed by an order server 26 in accordance with 
embodiments of the invention. 

In step 202, the order message sorter 38 of the order message manager 37 receives 
an input order message 50-1 over the network connection 24 that includes an input 
document 62. For example, the embedded order type 64-1 indicates that the input order 
10 message 50-1 is an order status inquiry that requests the current status of an order that a 
customer previously submitted in a previous input order message 50. In such an example, 
the embedded input data set 44-1 includes information related to the status inquiry, such 
as the customer ID of the order and the order number for the previous order. 

In step 204, the order message sorter 38 parses the input document 62 to 
15 determine the order type for the input document 62 and the ordering function indicated by 
the order type. For example, the order message sorter 38 reads the header, order type 
element, or first lines of an XML input document 62 based on a predefined format that 
provides the embedded order type information 64-1 to obtain an extracted version of the 
order type information 64-2. In this example, the order message sorter 38 determines that 
20 the extracted order type information 64-2 indicates that the ordering function requested is 
a status inquiry (e.g., check status function) for a previously submitted order. 

In step 206, the order message sorter 38 selects a message processing module 40 
to process the input document 62 for the ordering function indicated by the order type 
information 64-1. For example, the order message sorter 38 selects a message processing 
25 module 40 that is suited to perform a check status function as indicated by the extracted 
order type information 64-2. 

In step 208, the order message sorter 38 transfers the input document 62 to the 
message processing module selected to process the input document 62. For example, the 
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order message sorter 38 transfers the input document 62 to a status message processing 
module 40 that can perform the check status function requested by the extracted order 
type 64-2. 

In step 210, the message processing module 40 parses the input document 62 to 
5 obtain an extracted input data set 44-2 from the embedded data set 44-1 in the input 

document 62. For example, the message processing module 40 that is performing a check 
status function parses an XML input document 62 having a predefined XML element that 
identifies the order information, such as customer ID and order number, in the XML 
document 62. 

10 In step 212, the message processing module 40 processes the extracted input data 

set 44-2 based on the ordering function indicated by the extracted order type 64-2. For 
example, the status message processing module 40 determines the identity of a previous 
order submitted to the order database 28, as indicated by the customer ID and order 
number provided by the extracted input data set 44-2. 

15 In step 214, the message process module 40 obtains data for an output data set 46- 

1 and prepares an output document 68 including an embedded output data set 46-2. For 
example, the status message processing module 40 obtains data for the output data set 46- 
1 by accessing the order database 28 to obtain the current status for the previous order 
indicated by the customer ID and order number in the extracted input data set 44-2. Then, 

20 in this example, the status message processing module 40 prepares an output document 
68 that includes an embedded output data set 46-2 based on the output data set 46-1 that 
includes the status information obtained from the order database 28. 

In step 216, the message processing module 40 sends out an output order message 
52-1 including the output document 68 and embedded output data set 46-2. The output 

25 order message 52-1 is one example of the output order message 52 of Fig. 1 . For 
example, the message processing module 40 sends the status information in the 
embedded output data set 46-2 in the output document 68 in an output order message 52- 
1 . The message processing module 40 sends the output order message 52-1 through the 
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input/output interface 36 of the order server 26 over the network connection 24 to the 
client 22. 

Figs. 6A and 6B illustrate an example of an input document 300 (e.g., 300-1 and 
300-2) in a predefined format configured in accordance with embodiments of the 
5 invention. Fig. 6 A shows the first part on the sample input document 300-1 and Fig. 6B 
shows the second part of the sample input document 300-2. The input document 300-1 
and 300-2 is one example of the input document 62 shown in Fig. 3. 

In reference to Fig. 6 A, a header section 302 of the input document 300 provides 
information on the source of the input document 300, indicated by the <FROM> tag and 

1 0 the destination of the input document 300, indicated by the <TO> tag. The source 
typically is one company (e.g., an OEM) that is sending an input order message 50 
containing the input document 300 to another company (e.g., a vendor supplying one or 
more components to the OEM). Each company is identified by a unique number or 
identifier, as indicated, for example, by the identifier 306 for the company originating the 

15 input document 300. The identifier 306 is based on a domain of numbers or identifiers 
that identify each company, as indicated, for example, by the identity domain 304, which 
indicates a numbering domain that is referred to, as a hypothetical example in Fig. 6A, as 
the XYZ domain. In another example, the identity domain 304 is based on the Dun and 
Bradstreet D-U-N-S® (Data Universal Numbering System) system that provides unique 

20 identifiers for business entities, such as corporations. 

An authentication section 308 includes information from the sending company 
that the receiving company uses to authenticate the input document 300 as coming from a 
legitimate customer of the vendor. For example, the authentication section 308 includes a 
user identification (e.g., identification number or code) and a password for that user. 

25 A data section 3 1 0 provides the payload or data section for the input document 

300. The data section 310 provides the data for the input message data set 44, which the 
message processing module 40 extracts from the input document 62, as described for Fig. 
4. The payload ID 312 provides a unique number that can be used by the sender's (i.e., 
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client's) ordering process 30 and the receiver's (i.e., vendor's) order message manager 37 
to identify the input document 300. The message name entry 314 indicates the category 
for the command shown in the command entry 316 included in the data section 310. As 
shown in Fig. 6B, the message name entry 314 indicates that a task category (e.g., 
5 "config") that is for tasks related to configuration of the component that the sender is 
ordering. The command entiy 316 indicates a command for a specific task, shown for 
example in Fig. 6B as "list__boms", which indicates to return to the sender (e.g., 
customer) of the input document 300 a list of the bill of materials (BOMS) for a product 
sold by the receiver (e.g., vendor) of the input document 300. The parameters section 3 1 8 
10 lists parameters associated with the command 3 1 6, which indicates, for example, the 
price list to be used for this product (e.g., a price list identified by "1 108"), the product 
the customer is considering ordering (e.g., as identified by "ABC2501"), and other 
information. 

In one embodiment, the task categories that can be shown in a task category entry 
15 316 include configuration, pricing, addressing, order status, order submittal, kit 

references, zero pricing, and administration. Each task category includes commands that 
a customer can use to perform ordering tasks in that category. These commands 
correspond to an API (application programming interface) implemented in the message 
processing modules 40 of the order message manager 37 of the order server 26. See 
20 Appendix A for a listing of the commands in the API. 

Each task category is summarized in the following: The configuration category 
includes tasks related to configuring a product that the customer is considering ordering. 
The pricing category includes tasks related to pricing a product, such as discounts for a 
particular market segment of customers. The addressing category includes tasks related 
25 to customer addresses, such as listing the address of a current customer or providing an 
address for a new customer. The order status category includes tasks related to the status 
of an order, such as requesting the current status of an existing order. The order submittal 
category includes tasks related to submitting an order from a customer, such as ship-to 
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information, bill-to information, contact information, shipping method, and other 
information. The kit references category includes tasks related to specific configurations, 
such as configuration kits for products to be shipped to specific countries. The zero 
pricing category includes tasks related to components, such as power cables, that are not 
5 priced separately, that is, the price for a component (e.g., router) covers the price for the 
zero price components (e.g., power cable for the router). The administration category 
includes tasks related to administering and operating the order message manager 37, such 
as diagnostic tasks. Appendix A provides examples for commands for these task 
categories. 

10 Figs. 7A through 7E illustrate an example of an output document 330 (e.g., 330-1, 

330-2, 330-3, 330-4, and 330-5) in a predefined format configured in accordance with 
embodiments of the invention, provided by a vendor in response to the input order 
document 300 shown in Figs. 6A and 6B. Fig. 7A shows the first part of the sample 
output document 330-1 ; Fig. 7B shows the second part of the sample output document 

15 330-2; Fig. 7C shows the third part of the sample output document 330-3; Fig. 7D shows 
the fourth part of the sample output document 330-4; and Fig. 7E shows the fifth part of 
the sample output document 330-5. The output document 330 is one example of the 
output document 68 shown in Fig. 4. 

In reference to Fig. 7 A, the header section 332 provides identifiers for the sender 

20 and the receiver of the output document 68, in a manner similar to that described for the 
header section 302 of the input document 300, as described previously. 

In reference to Fig. 7B, a response message entry 340 indicates the category for 
the response. As shown in the response message entry 340, the category is "config", 
which corresponds to the category indicated in the message name entry 314 of the input 

25 document 300. A data section provides the payload or data for the output document 330. 
The data section is indicated by entries 334 through 338, and entries 360 through 376, as 
shown in Figs. 7B through 7E. This data section provides the data for the output message 
data set 46, which the message processing module 40 incorporates in the output document 
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330, as described for Fig. 4. For example, the input document 300 provides a command 
to list the BOMS for a product, and thus the output document 330 provides sample lists 
of subcomponents for this product, such as power cables 334, 336 and 338, software 360 
through 372, documents 374, and rack mount kits 376. The customer receives the output 
5 document 330 and then typically selects the desired subcomponents from those listed in 
the output document 330 (e.g., a specific type of power cable needed) when configuring 
the customer's order. 

In reference to Fig. 7B, the class section 334 indicates a class of components for 
the system requested in the input document 300, for example, a class of power cables as 

10 shown in a product entry 342. In one embodiment, the product entry 342 can indicate a 
product, component of a product, or subcomponent of a component. The hash entry 344 
indicates a hash number that can be used to locate information on the class of components 
in the vendor's order database 28. The full path entry 346 indicates the full path to the 
class information in the vendor's order database 28. In one embodiment, the full path 

1 5 entry 346 follows a hierarchical tree format (e.g., parent:child:grandchild). The 
description entry 348 provides a text description of the component indicated in the 
product entry 342. 

The item entries 336 and 338 indicates specific items within the class indicated by 
the class entry 334 (e.g., power cables). For example, the item entries 336 and 338 

20 indicate specific types of power cables (e.g., USA and Italian power cords) within the 
class of power cables. The item entries 336 and 338 shown in Fig. 7B are shown as one 
example, and more entries (e.g., power cords for additional countries) can be included 
under the class entry 334. 

In reference to Figs. 7C and 7D, the class entry 360 indicates a class of software 

25 for the product indicated in the input document 300. The minor class entries 362 and 368 
indicate minor classes or subclasses of software components under the software class 
indicted by class entry 360. Two software items 364 and 366 indicate specific software 
versions under the minor software class indicated in the minor class entry 362. Two 



CIS00-3846 



-21 - 

software items 370 and 372 indicate specific software versions under the minor software 
class indicated in the minor class entry 368. 

In reference to Fig. 7E ? the class entry 374 indicates a class of documentation 
related to the product indicated in the input document 300. The class entry 376 indicates 
5 a class of rack mount components for the product indicated in the input document 300 
(e.g., components that enable the mounting of the product in a rack setup). 

The techniques of the invention do not require that the output document 330 
include classes, minor classes, and items as shown in Figs. 7A through 7E, which are 
shown as one example only of a predefined format. 

10 Thus, as shown by the output document 330, the predefined formats shown in 

Figs. 7A through 7E allow the customer to readily transfer the data in the output 
document 330 to a customer's application, such as an ordering process 30 or other 
software application performing on the client. For example, the ordering process 30 can 
read the output document 330 received from the vendor and efficiently interpret the data 

1 5 in the output document 330 by referring to the tags, such as <PRODUCT>, <CLASS>, 
<MINORCLASS>, <ITEM>, and other tags, to classify and interpret the data. Then the 
ordering process 30 can automatically convert the data into a local format used in the 
customer's client database 31 without requiring ongoing manual or human intervention 
(after an administrator or other operator sets up an automatic mapping between the 

20 predefined format of the output document 330 to the format used in the client database 
31). 

In summary of the approach of the invention, a client 22 (e.g., customer) provides 
an input order message 50 that includes an input document 62 providing a command and 
data in a predefined format. The client 22 sends the input order message 50 to an order 
25 message manager 37 performing on an order server 26. The order message manager 37 
interprets the input document 62 based on the predefined format, and an order message 
sorter 38 determines an order type 64 for the input document 62. Based on the order type 
64, the order message sorter 38 directs the input document 62 to a message processing 
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module 40 which implements one or more commands in an order processing API 
implemented on the order server 26. The message processing module 40 extracts the 
input data set 44 from the input document 62 and processes the input data set 44 based on 
the data and the command indicated in the input data set 44. The message processing 
module 40 generates an output data set 46 based on the input data set 44, such as by 
obtaining data from the order database 28 to use in generating the output data set 46. The 
message processing module 40 then incorporates the output data set 46 in an output 
document 68 to be sent in an output order message 52 to the customer, providing a 
response to the input order message 50 sent from the client 22. 

While this invention has been particularly shown and described with references to 
preferred embodiments thereof, it will be understood by those skilled in the art that 
various changes in form and details may be made therein without departing from the 
spirit and scope of the invention as defined by the claims that follow Appendix A. 

For example, the input document 62 and output document 68 can be based on 
other types of documents than an XML document, such as HTML (Hypertext Markup 
Language) documents, SGML (Standard Generalized Markup Language) documents, or 
other types of tagged documents. 

In other examples, the network connection 24 is a local area network (LAN), such 
as an Ethernet, a wide area network (WAN), an enterprise wide network, a direct line 
connection, or other suitable network or communications connection. 

In another example, the order server 26 is a PC server computer, UNIX server or 
workstation, minicomputer, or other type of suitable server computer. 

In a further example, each message processing module 40 can handle a variable 
number of commands. For example, one message processing module 40 can process all 
of the commands in one task category. In addition, each message processing module 40 
can be implemented on a separate server. Generally, the order message manager 37, 
order message sorter 38, and message processing modules 40 are not required to perform 
on the same computer (e.g., order server 26). That is, the functions of the order server 26 
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can be implemented in a distributed manner, such as by several computers connected in a 
local area network or by the Internet. The functions of a single message processing 
module 40 can also be implemented in a distributed computing or distributed object 
manner. Furthermore, the data from the input message data set 44 can be divided into 
subunits of data that can be processed by the different message processing modules 40, 
for example if the input message data set 44 includes a large number of different types of 
data or includes multiple commands. 
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APPENDIX A 

The following appendix entitled "Listing of Order-Related Task Categories and 
Commands," provides an example of order-related task categories and commands 
suitable for use in order messages illustrating one approach of the invention and is meant 
to be considered as part of the detailed disclosure of embodiments of the invention. See 
the discussion for Figs. 6A and 6B for a description of the task categories. The 
commands described in Appendix A, however, are to be considered as an example only, 
and it is to be understood that this example is not meant to be limiting of the invention. 
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Listing of Order-Related Task Categories and Commands 



********************************** 

pkl_api__msg. 1st messages 

pkl_generic_select . 2 
pk 1 ge t g tm_di s c oun t . 2 
pkl_l i s t_car r i er . 2 
pkl_list_market_segment . 2 
pkl__list_service__i terns . 2 

pklst/2.0 
generic__s elect 
username=userl 
pas s word=xxxxxxx 1 

sql_stmt=select distinct allow_dis count from api_cco_plist_mapping 
where prlist_id= T 1108 1 

pklst/2.0 

ge t_gtm_di s count 

username=userl 

pas sword=xxxxxxxl 

cus tomer_number=l 00070 

po_type= 

end_user_name= 

end_u s er_c oun try = 

end__user_market_segment= 

i tem_id=ABC 1605-R 

pklst/2. 0 
lis t_car r i er 
username=userl 
pas s word=xxxxxxxx 

pklst/2 . 0 

1 i s t_mar ke t_s egmen t 

username=userl 

password=xxxxxxxx 

pklst/2. 0 

lis t_servi ce_i terns 
username=userl 
password=xxxxxxxx 
price_list=1108 
conf ig_i tem=ABC2 501 
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************************************ 

adr_api_ms g .1st me s s age s 

adr_list_addresses . 2 . BILL 

adr_list_addresses . 2 . SHIP 

adr_list__customer . 2 

adr list pricelists.2 
10 adr list rel customer. 2 

adr__new_def ine_address . 2 

adr_new_def ine_contact . 2 

adr_new_list_con tacts . 2 

adr_temp_to_perm_addr . 2 
1 5 adr_temp_to_perm_contact . 2 

addressing/2 . 0 
ne w_l i s t__addr e s se s 
username=userl 
20 password=xxxxxxxx 

cus t omer_number=l 00070 
address_type=BILL 

25 addressing/2 . 0 

ne w__l i s t_addr e s s es 

username=userl 

password=xxxxxxxx 

cus tomer__number=l 00070 
3 0 addres s_type=SH I P 

addressing/2 . 0 
list customer 
35 username=userl 

pas sword=xxxxxxxx 

addressing/2 . 0 
40 list pricelists 
username=userl 
pas sword=xxxxxxxx 
cus t omer_number=l 00070 

45 

addressing/2 . 0 
lis t_rel__cus tomer 
username=userl 
pas sword— xxxxxxxx 
50 customer number=100070 



Addressing/2 . 0 
New Define address 



CISOO-3846 



username=userl 

pas s word=xxxxxxxx 

Cus tomer_Number=l 00070 

customer==CUSTOMERl 

addressl=TESTING 

address2=TESTING AGAIN 

address3=TESTING LAST TIME 

city- SAN JOSE 

state=CA 

zip=95134 

Country=US 

addressing/2 . 0 

new_define_contact 

username=userl 

pas s word=xxxxxxxx 

con t a c t_type=B I LL 

cus tomer_number=l 00070 

last_name=a 

addr es s_id==4 42008 

addressing/ 2 . 0 

new_l jl s t_contacts 

username=userl 

pass word=xxxxxxxx 

cus tome r_number=l 00070 

contact__type=BILL 

customer id=100072 



addressing/ 2 . 0 

temp_to_perm_addr 

username=userl 

password=xxxxxxxx 

cus tomer_number= 1 0 0072 

address id=442008 



addressing/2 . 0 
temp_to_perm_contact 
username=userl 
pas s word=xxxxxxxx 
contact id=252867 
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cf g_api_msg. 1st messages 

cfg api_msg.lst 

cf g__conf ig__check . 2 

cf g_kit_check . 2 

cf g__l i s t_bom s . 2 

cf g_list_classes . 2 

cf g_l is t__conf igurables . 2 

cf g_list_f amilies . 2 

cf g_l i s t_i terns . 2 

cf g_list__visible . 2 

cf g__x_check . 2 

config/2. 0 
conf ig_check 
username=userl 
pas s word=xxxxxxxx 
price list=1108 
z er o_pr i ce=N 
country= (None) 

config/2. 0 
kit_check 
username=userl 
pas s word=xxxxxxxx 
country=canada 

config/2. 0 

list_boms 

username=userl 

pas sword=xxxxxxxx 

GUIVERSI0N=4 . 5 

price_list=1108 

list_type=SPECIFIC 



config/2 . 0 

list_classes 

usernaicie=userl 

password=xxxxxxxx 

price_JList=1108 

conf igur able=ABC 1605-R 

lis t_ type=ALL 



config/2 . 0 

list__conf igurables 

username=userl 

password=xxxxxxxx 

price_list=1108 

family=9415 

lis t type=ALL 
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conf ig/2 . 0 
list_families 
username=userl 
5 password=xxxxxxxx 
price_list— 1108 
f ami ly__type=ALL 
lis t_type=ALL 

10 

conf ig/2 . 0 
list_i terns 
username=userl 
pas s wor d=xxxxxxxx 
15 price__list=1108 

conf igurable=ABCl 605-R 
parental 600-R SOFTWARE 
lis t_type=ALL 

20 

conf ig/2 . 0 
lis t_vi s ible 
username=userl 
pas s word=xxxxxxxx 
25 price_list-1108 

conf ig/2 . 0 
x_check 

username=userl 
30 password=xxxxxxxx 
price_list=1108 
zero price=N 
country= (None) 

35 

*********************** 

pricing_api__msg . 1st messages 

40 pr_def _price2 1 

pr lst_pricelists21 

pr 1st prices21 

pr_set_mk t2 1 

pricing/2 . 0 
45 define_price 

us ername=us er 1 

pass wor d=xxxxxxxx 

price_list=1108 

50 

pricing/2 . 0 
list_pricelists 
username=userl 
password=xxxxxxxx 



CISOO-3846 



- 30 - 



list_type=ALL 



5 pricing/ 2 . 0 
list_prices 
username=userl 
password=xxxxxxxx 
price_list=1108 
10 item_type=CO 

lis t_ type=QUE RY 

pricing/2 . 0 
set_marke table 
15 username=userl 

password=xxxxxxxx 
price_list=1108 

20 

********************************* 
s ubm i t_ap i_m s g . 1st messages 

sub_list21 
25 sub_smt21 
sub_view2 1 

submit/ 2 . 0 
list_orders 
30 username=userl 

password=xxxxxxxx 
list__type=SPECIFIC 

submit/ 2 . 0 
35 submit_order 

username— userl 
pas s word=xxxxxxxx 
pr i ce__l i s t= 1 1 0 8 
test_only=N 

40 purchase_order=sgs_ushirsat_ver21__t5__2011 

terms=l% Net 30 

order__type= STANDARD 

po_type=Demo /E val 

ship_to_id=4 74453 
4 5 ship_to_name=CUS TOMER2 

ship_to_addres s 1=TBD 

ship_to_addr es s 2 = 

ship to__address3= 

ship_t o__ci ty=TBD 
50 shxp__to_county= 

ship_to__s tate= 

ship__to_zip= 

ship_to_country=CZ 

ship_to_contact_id= 
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ship__to_contact= 
ship_to_j?hone= 
s h ip__ t o_jf: ax= 
ship_to_emai 1= 
ship_to__contact_dept= 
cus tomer_nuitLber= 10247 9 
contact__name= 
con tac t_phone= 

contact_fax=ICS VERSION 4 . 05 / 30May2000 

bill_to_id=440555 

bill_to_name=ABC SYSTEMS INC US 

bill__to_addressl=GSTR 5A 

bill__to_address2- 

bill_to_address3= 

bill_to__city=DIEBURG 

bill_to__county= 

bill_to_state= 

bill_to_zip=64807 

bi 1 1_ to__coun try=DE 

bill_to_contact_id=2 60575 

bill_to__contact==JSMITH 

bill_to_phone= 

bil 1__ t o__f ax= 

bi 1 l_to__emai 1= 

end_user_cus tomer_name=CUSTOMER2 

end__us er_addr e s s_pos tal_code= 

end_us er_addr es s_ci ty=TBD 

end__u s er_addre s s_s t a te__i d= 

end_u s er_addr e s s^coun t ry_i d= 

end_u s er_addr e s s_i d- 4 7 4 4 5 3 

recipients_name= 

shipper__account= 

shipment method=AAME5 

f reign t_tena=C IP Duty Unpaidl 

merge=N 

f ob_point=Destination 
reques ted_ship_da te=2 0000609 
shipment__priority= 
email_order__to=yyyyyyyy@abc . com 
f ax_email__indicator=Email 
ab c__s a les_rep= 
shipping__notes= 
notes- 
car ton_note= 
discount^ 

order_total=24004 . 00 
ship_partial=N 
early_ship=N 
product_for_resale=N 

conf ig/1 . 0 
conf x g_check 
section_id=l 
country= 
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spare_items 
section id=3 



spar e_i tern s 
section id=4 



conf ig/1 . 0 
conf i g_che ck 
section_id=5 
country= 

line atr 

par en t__s e c t i on_i d= 1 

lla_euser_address_l=sgsverll_address_l 
1 1 a_eu s er_addr e s s_2 - s gs ver 1 l_addr e s s__2 
lla_euser_address_3=sgsverll_address_3 
lla_euser_address_city=sgsverl l_ci ty_San Jose 
lla_euser_addres s__country__id=US 
1 la_eus er__addr es s_id= 95 135 

1 la_euser_addres s__po s tal_code= s gs ver 1 l_pos tal_code_9 5 134 
1 la_euser__addr es s_s tate_i d=CA 

I la_eu ser_cu s t omer_name=s g s ver 1 l_cu s t omer_name 

lla_euser_marke t_segment=sgs ver 1 l_marke t_segment_Computer Software 
sgsverl_l 

lla_euser_category=sgsverll_category_is 
line_atr 

par en t_s e c t i on__i d=5 

lla_euser_address_l=sgsverl2_l_address_l 

I I a_eu s er_addr e s s_2 = s gs ver 1 2_l_addr e s s_2 
lla_euser_address_3=sgsverl2_l_address_3 

1 1 a_eu s er_addr e s s_ci ty— s gs ver 1 2_ci ty__S an Jo s e 

I la_euser_addres s_country_id=US 

I I a_eu s er_addr es s_i d= 9 5 1 3 5 

lla_euser_addres s_po s tal_code=sgs3 l_pos tal_code_95 1 3 4 

I la_euser_addres s_s tate_i d=CA 

I I a_eu s er_cu s tomer_name=s gs ve r 1 2_l_cus tome r_name 

lla_euser__market_segment=sgsverl2_l_market__segment_Computer Software 
sgs2~l 

lla_euser_category=sgs31_category_is 

I ine_s erv_a tr 
section_id=6 
parent_section_id=:l 

I I a_s r v__i tem=s gs_sr vver l_i t emid 
lla_srv_type=24*7 Service 

1 1 a_s r v_qty = 1 
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lla_srv_list_price=1000 . 00 
11a srv cost price=1000 . 00 
lla_srv_di s count— 0 

11a s rv_s i t e_adr_l = s gs__s r vver l__addr e s s_adr_l 
1 1 a _ s rv~s i t e_adr_2 = s gs_s r we r l_addr e s s_adr_2 
1 1 a"~s r v si te_adr_3=s g s_s rvver l_addre s s_adr_3 
lla~srv~~site adr city=sgs_srvverl_adr_city_santa_ Clara 
11a s rv_s i te__adr__coun t ry_i d=US 
1 1 a~s r v_s i te_a dr_i d=2 9 3 8 3 9 

11a srv site adr post__code=sgs_srvverl_postcode232909202 

11a s rv_s i te_adr_s ta t e_i d=s gs__s r vver l_s ta te_id_2 322 

lla~~ srv~site customer_name=sgs_srvverl_customer_name_CUST0MER3 

1 1 a~s rv~c tac t_id=2 8328 

11a srv ctact f irst_name=sgs_srvverl_ctact_f irst_name 
11a s rv_c tac t_l as t_name= s gs_s r vver l_c tac t_l a s t_name 
lla_srv_ctact_phone=sgs_srvverl_ctact_phone 
lla_srv_ctact_f ax=s gs_s rvver l_c tac t_f ax 

11a srv ctact email=sgs_s rvver l_c tac t_email_ehe what is the E-mail 

1 1 a_s rv_c tac t_dep t= s gs_s r v ver l_c tac t_dep t 

11a srv_ctract_quote=sgs_srvverl_ctract__quote__quotationj 

lla~srv_ctract_number=sgs_srvverl_ctract_niimber 

lla_srv_ctract_type=sgs_srvverl_ctract_typee 

lla~srv_ctract_bill__addr=sgs_srwerl_ctract_addr ef jkew addresss 
lla~srv ctract_bill_contact=sgs_srvverl_ctract_bill_contact numerj 

line_serv_atr 

section_id-7 

parent_section_id=5 

lla_srv_i tem=sgs__srvverl2 l_i temid 

lla_srv_type=24*7 Service 

1 1 a_s r v_q ty=l 

lla__srv_list_price=1000 . 00 
lla_srv_cost_price=1000 . 00 
11a srv_discount=0 

lla~srv_site_adr__l=sgs_srvverl21_address_adr_l 

I la_s rv_s i te_adr_2 =s gs_s r vver 1 2 l_addre s s_adr_2 

I I a_s r v_s i t e_adr_3= s gs_s r we r 1 2 l_addr e s s_adr_3 
lla~srv_site_adr_city=sgs_srvver!21_adr_city__santa_ Clara 
11a srv site__adr_country_id=US 

1 1 a~s rv~s i te_adr_i d=2 931039 

11a srv_site_adr_post__code-sgs_srvverl21_postcode232 909202 

11a srv site adr state_id=sgs_srvverl21__state_id_2322 

11a"" srv" site customer name=sgs__srvverl21_customer_name_CUSTOMER3 

lla~srv~ctact_id=28328 

lla_srv_ctact_first_name=sgs_srvverl21_ctact_f irst_name 
11a srv ctact_last__name=sgs_srvverl21_ctact_last_name 
11a srv ctact phone=sgs__srvverl21_ctact_phone 
1 1 a_s rv_c t a c t_f ax= s g s_s r vver 1 2 l_c t a c t_f ax 

11a srv ctact email=sgs srvverl21_ctact_email_ehe what is the E-mai 
id ~~ ~ ~ ~ 

1 1 a__s rv c t a c t_dep t=s gs_s rv ver 1 2 l__c tac t_dep t 
11a srv ctract_quote=sgs_srvverl21_ctract_quote_quotationj 
11a srv ctract number-sgs_srvverl21_ctract_number 
11a srv ctract type=sgs_srwerl21_ctract_typpe 
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lla srv ctract_bill_addr=sgs_srvverl21__ctract__addr ef jkew addresss 
lla _ srv~ctract3^ill_ contact=s g s _ srvverl21 _ ctract _ bil numer j 

lla_po_line_ref=sgsverl2322_l_part_lineref 



submit/2 . 0 
view_order 
username=userl 
pas s wor d=xxxxxxxx 

email_order_to=yyyyyyyyyy@abc . com 
sgs_ushirsat_ver2 l__t5_2 Oil 

******************************** 
status__api_msg. 1st messages 



status/2 . 0 

change_no te 

username=userl 

pas sword=xxxxxxxx 

f ile_name=/tmp/st_change_note21 

emai l_s tatus_to= 

or der__header=order_s tatus , f reight_term , fob , sales_agent , currency , 
payment_term,fob,bill_business_name,bill_addressl ,bill_address2 , 
bill address3 ,bill_city ,bill_state , ship_business_name , ship_addressl , 
bill~f ax , bill_city , ship_city , ship_s tate , original_sys tem_ref erence , 
line_note 

order_detail=product_number , ordered_quanti ty , promise_date , 
new_promi se_date 
include_previous=Y 
1 is t_type=QUERY 



ORDER BY tl ,po_number; 

status/2.0 

order_note 

username=userl 

pas sword— xxxxxxxx 

f ile_name==/tmp/order__note21 . log 

email_status_to=yyyyyyyyyyyy@abc . com 

order_header-order_s tatus , f reign t_term , fob , sales_agent , currency , 
payment term , f ob , bill bus iness_name ,bill_addressl , bill_address2 , 
bill_address3 ,bill_city ,bill_state , ship_bus3.ness_name , ship_addressl , 
bill_f ax , bill_ci ty , ship_ci ty , ship_s tate , original_sys tem__ref erence , 
line_note 

order_detail=line_s tatus , product_number , ordered_quantity , uni t__pri 
ext_price , promise_date , line_note 
include_previous=Y 



CIS00-3846 



-35- 



LIST TYPE=SPECIFIC 



status/2. 0 

order__note 

username=userl 

password=xxxxxxxx 

f i le_name= / tmp/ or der__no te2 2 

email status_to= 

order__header=ALL 

o r de r_de ta i 1 =ALL 

include_previous=Y 

LIST TYPE=ALL 



status/2. 0 

pod__note 

username=userl 

pa s s wo rd=xxxxxxxx 

f ile_name- / tmp/pod_no te2 1 

email_s ta tus_to= 

pod_list=POD_PONUMBER, RECEIVING_CUSTOMER_NAME , AC TUAL_DE L IVERY_D ATE 

include_previous=Y 

lis t_type=QUERY 



status/2. 0 
shipmen t_no te 
username=userl 
pas sword=xxxxxxxx 

f ile__name=/tmp/st_ship_note_21 . dat 
email_status__to= 

order_header=ORDER_NUMBER 7 ORIGINAL_SYSTEM_REFERENCE , PAYMENT_TE RM , 
SH I P — METHOD 

order_detail— MAJOR_LINE_NUMBER , PRODUCT_NUMBER , ORDE RE D_QUANT I T Y 
ship_header==SHIPjSET_NUMBER, SHIPPED_DATE , BATCH_NAME , TRACKING_NUMBER 
ship~detail=LINE_UNIT , LINE_SHIP_QTY , LINE_BO_QTY 
ship_carton=CARTON_ID , SERIAL_NUMBER 

pod_list=RECEIVING_CUSTOMER_NAME , AC TUAL_DE L I VERY_D ATE 

include_previous=Y 

lis t_type=ALL 
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******************************************* 

adm api msg.lst messages 

adm_list_parameters . 2 
5 adm__run__diagno s t i c . 2 
adm_set_parameter . 2 
adm_validate_user . 2 

admin/2 . 0 
10 list_parameters 
username=userl 
password=xxxxxxxx 
lis t_type=ALL 

15 

admin/2 . 0 
run__di agnostic 
username=user 1 
password=xxxxxxxx 
20 di agnos t i c=S HOW_PARAME TE RS 

admin/2 . 0 
set_parameter 
25 username=userl 

pas s word=xxxxxxxx 

master_host zzzzzzz.abc.com 

30 admin/2.0 

validate_user 
username=userl 
pas s word=xxxxxxxx 

35 

********************************** 

zeroprice_api_msg . 1st messages 

40 zp define21 

zp_delete21 

zp_list21 

zerop/2 . 0 

def ine_rule 
45 username— userl 

password=xxxxxxxx 

zerop/2 . 0 
50 delete_rule 

username=userl 
pas sword=xxxxxxxx 
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zerop/2 . 0 
list_rules 
username=userl 
5 password=xxxxxxxx 
lis t_type=ALIi 
configurable=ABC2515-CH 



10 
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